In modern day computing, almost all software applications have a user-interface. Software application interfaces have evolved over the years, starting with console based interfaces in early machines, to user-interfaces which have graphical elements to represent control elements in the current modern times. Historically, the expectation on the interfaces to software applications has risen and the demand for highly attractive visual appearances continues to increase. A graphical control may be formed by an individual graphical element, or a combination of graphical elements, having a control function, sometimes called a widget. Where the combination results in an identifiable shape, the combination may be adjusted, such that, when adjusted combinations are displayed in sequence, such may result in an animation of the identifiable shape (eg. a graphical animal, such as a cat).
Control elements in user-interfaces traditionally have been pre-defined by various user-interface toolkits. Typically, building control elements is a difficult and mundane task that requires much code to correctly implement the desired behaviour. Graphical user-interfaces (GUIs) traditionally do not have much animation in them because the effort required to implement such animation has been considered additional effort in building the toolkits.
When animated control elements are required, additional effort is required to author the various animations that could occur. For example, in the situation of a three-state graphical button, the combinations of state changes that could occur are from normal to over state, over to down, down to normal, normal to down, over to normal, and down to over states. This would require the animation for all of the state changes to be defined to ensure that the controls will always animate between the different state change combinations.
Further, some state changes may need to be specified by a corresponding animation. In the present example, six separate animations may be required.
For control elements (eg. a GUI “button”) that animate, multiple incoming events can cause the control to quickly change appearance. A naive approach to this circumstance would be to stop any current animation and then perform the new animation. This would result in the animations not animating smoothly since the first animation is stopped prematurely before the next animation is started. Another possible solution would be to discard events (or skip processing of events during animation), but this would cause logic for the GUI button to be skipped. An alternative method for handling such scenarios is to defer processing of events until the animation has completed. Such a solution would allow smooth animations, but would result in an unresponsive user-interface as the animation effects would occur some time after the actual event was generated, by a mouse click for example.
There are other solutions that solve the above problems which de-couple the animation from the event discrimination logic. On detecting user input invoking a change, the event is processed and the logic for the corresponding destination state is executed. Once logic has been performed, the animation is initiated by looking up the desired transition animation using the current visual state of the control element, and the current state. This allows the user interface to be responsive to input since unnecessary visual states of the controls are then skipped since the animation from the current visual state to the state of the current control element is always performed. While advantageous, such a solution is limiting as the animation performed is determined by the change in states, rather than the incoming events.
While the above issues make it difficult to build user-interfaces, one may take the approach of explicitly handling each animation with program code. Whilst this can work, it does result in widgets that are inflexible and difficult to customise and update the appearance.